<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN2">
<html>
<head>
<title>Deployment Packs</title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <meta http-equiv="Content-Style-Type" content="text/css">
    <link href="http://dev.eclipse.org/default_style.css" rel="stylesheet" type="text/css">
</head>
<body bgcolor="#ffffff">

<table width="100%">
<tr><td style="background:#0080C0"><b><span style="color:white">Proposal</span></b></td></tr>
</table>
 
<h1>Deployment Packs</h1>
 
<blockquote> <b>Summary</b>  <br>
Deploying an RCP based application involves constructing a complete Eclipse install.
  As such, any third-party, platform-specific fragments and Eclipse
  launchers (executables) must be included in the deployment for each target
  platform. This is in contrast to deploying add-on function typical of tooling
  scenarios which contain mostly developer written and platform-independent plug-ins.
  This document describes a deployment pack download which simplifies the construction
  of complete RCP applications for multiple platforms.
   <p>
<font size="-1">Last modified: October 21, 2004</font> 
</blockquote>
<p>
<h3>Background</h3>
<p>Developers are setup with development and target Eclipse installs for one platform.
They merrily configure their target and write their code, launching and debugging
  as they go. When it comes time however to deploy their application, they face
  a challenge -- their target includes only the launcher (Eclipse executable)
  and fragments for their current target platform. This is disappointing because
Eclipse, and in fact Java, is platform independent. In general, an application
  written for one application should at least run on other supported platforms.
<p>Currently the workaround for this is cumbersome, very manual and thus
  very error-prone. It goes something
like this:</p>
<ol>
  <li>Download the appropriate Eclipse drops for all of the target platforms</li>
  <li>Unzip them over top of one another in your target directory</li>
  <li>Check-out the platform-launcher project from dev.eclipse.org</li>
  <li>Check-out the org.eclipse.platform-feature project from dev.eclipse.org</li>
  <li>Carefully and manually rename the org.eclipse.platform feature to match your
    requirements. Take care to update the build.properties and other elements
    as appropriate. Alternatively you can create a simple feature and copy/update
    the build.properties
    from org.eclipse.platform-feature.</li>
  <li>&lt;include&gt; or otherwise identify your new feature in your product's feature structure.</li>
</ol>
<h3>Proposed Solution</h3>
<p>To make this easier we propose that Eclipse.org supply a <em>deployment pack</em> download which effectively eliminates steps 1-5 outlined above. The deployment
  pack is a single zip containing all possible (platform-specific) fragments
  for all of the Eclipse SDK as well as a special feature which contains launchers
  and
  essential
  root
  files (e.g., startup.jar) for all supported platforms.</p>
<p>Using this deployment pack allows steps 1-5 to be compressed into
<ol>
  <li>Download the deployment pack and unzip into the target directory</li>
  <li>&lt;include&gt; the launcher feature in your product's feature structure</li>
</ol>
<p>The deployment pack is approximately 15MB in total. The bulk of this
  is taken up by SWT fragments (8 @ 1.5MB each). Another 2.5MB for all the launchers
  and a bit here and there for other fragments. The net result however is a setup
  which allows users to write their applications on one machine and build deployable
  zips etc. for all possible configurations with the push of a button.</p>
<p>Creating the deployment pack can be reasonably integrated into the current build
  infrastructure.</p>
<h3>Alternatives</h3>
<p>The need for deployment packs is felt mostly in RCP scenarios. As such, we could
  consider including the contents of the deployment pack in the RCP SDK drop
  proper. Unfortunatly this doubles the size of the SDK drop (currently
  17MB) and clutters the target environment. Further there is still a need for
  platform specific RCP SDK drops to carry the appropriate source. So the additional
  15MB would be replicated 8 times in the various RCP SDK zips.</p>
<h3>References</h3>
<ul>
  <li>  <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=76725">76725</a></li>
</ul>
</body>
</html>
